5분만에 읽는 도커 기본 – 도커 데몬, 오케스트레이션, 도커 스웜

#한국어블로그

#Docker

Lee Sujae

2022.07.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드의 수재입니다.
저번 글에서 정리했던 도커의 개요와 명령어에 이어서 내용을 정리해보았습니다.

도커 데몬

도커는 Server-Client 아키텍쳐
- 컨테이너와 이미지를 관리하는 도커 서버(=dockerd프로세스로 작동하며 이를 도커 데몬이라고 함)
- 서버에 API를 입력할 수 있도록 CLI를 제공하는 도커 클라이언트

출처 : 도커 공식 페이지

dockerd 명령어로 다양한 옵션을 설정한 도커 실행 가능
- 혹은 도커의 설정 파일을 수정해도 됨
- Docker Desktop for Window을 이용하는 경우 docker desktop 에서 관리
- -H옵션을 사용하면 Docker Remote API로 원격 통신 가능
  - WSL에서 Docker Desktop for Window을 이용하는 경우에는 다음 옵션을 활성화하면 내부에서 TCP 통신이 가능
- --tlsverify 옵션으로 TLS 보안을 적용할 수 있음
  - dockerd --tlsverify \ --tlscacert={ca 경로} \ --tlscert={cert 경로} \ --tlskey={key 경로} \ -H localhost:2376 \ ~~
  - DOCKER_CERT_PATH , DOCKER_TLS_VERIFY등의 환경 변수를 설정하면 평소에 편하게 이용 가능
- --storage-driver 옵션으로 도커의 스토리지 드라이버를 변경 가능
  - dockerd --storage-driver={OverlayFS, AUFS, Btrfs, Devicemapper, VFS, ZFS}
  - 변경 후의 드라이버가 이전 드라이버와 다른 경우 이전의 이미지와 컨테이너는 사용 할 수 없음
스토리지 드라이버는 CoW 또는 RoW 방식을 사용
- 덕분에 스냅샷 파일을 불변 상태로 유지할 수 있음
데몬의 -D 옵션으로 디버그 모드를 활성화 할 수 있음
- dockerd -D
- 서비스로 구동했을 때는 로그 파일을 따로 찾아보자
혹은 도커 서비스의 커맨드로도 확인 가능
- 도커 데몬의 이벤트 실시간 스트림
  - docker events {--filter 'type=image/volume..'}
  - docker system events
- 실행 중인 모든 컨테이너 자원 사용량을 실시간 스트림
  - docker stats
  - 한번만 보고 싶다면 --no-stream 옵션을 추가
- 도커에서 사용하고 있는 이미지, 컨테이너, 로컬 볼륨에 관한 정보 출력
  - docker system df
CAdvisor, Prometheus, Node Exporter 등 3rd party 모니터링 도구를 이용하는 방법도 있음
코드로 도커를 원격 조정하고 싶은 경우 Remote API를 래핑한 라이브러리를 이용하자

오케스트레이션

여러 서버를 하나의 그룹으로 취급하는 클러스터를 관리하는 작업을 말함
- 스케쥴링, 서비스 디스커버리, 로드 밸런싱, 고가용성, 배포 관리 등이 가능
- 오케스트레이션 툴이 이런 기능들을 우선적으로 제공하며 툴에 따라 조금씩 기능의 차이가 있음
도커 스웜, 아파치 메소스, 쿠버네티스(and EKS), ECS 등을 많이 사용

도커 스웜

도커에서 제공하는 오케스트레이션 툴
도커 클래식(컨테이너로서의 스웜)은 여러 대의 도커 서버에 접근하는 하나의 단일 접근점을 제공
- docker run, ps등 일반적인 도커 명령어와 도커 API로 클러스터의 관리가 가능
- 공식 문서에서도 레거시로 다루고 있으니 스웜 모드를 사용하자
스웜 모드는 MSA를 다루기 위한 클러스터링 기능에 중점
- 오토 스케일링, 로드 밸런싱 기능을 자체적으로 지원
- 일반적으로 스웜 모드를 더 많이 사용
각종 정보를 저장하고 동기화 하는 분산 코디네이터, 클러스터 내의 서버를 관리하고 제어하는 매니저, 각 서버를 제어하는 에이전트를 스웜 클래식은 별도로 실행해야 하지만 스웜 모드는 자체 내장
매니저 노드와 워크 노드로 구성
- 앞으로 다른 오케스트레이션 툴에서도 많이 사용되는 개념
- 워커 노드를 매니저 노드에서 관리
  - 매니저 노드에서도 컨테이너가 생성될 수 있음
- 매니저 노드는 1개 이상 있어야하지만 워커 노드는 없을 수도 있음
- 매니저 노드를 다중화 하여 운영하는 것을 권장
  - 홀수 개의 매니저 노드 운용을 권장
docker swarm init명령어로 시작
- 호스트의 IP가 여러 개인 경우 사용할 IP 주소를 지정해야함
- docker swarm init --advertise-addr {ip address}
  - 출력되는 token 값은 새로운 노드를 클러스터에 추가하기 위한 비밀키
- 기본적으로 2377 포트를 사용하며 노드 사이의 통신에 7946/tcp, 7946/udp 포트를 이용하고, 스웜이 사용하는 네트워크인 ingress 오버레이 네트워크에는 4789/tcp, 4789/udp 포트 사용
  - 따라서 이 포트를 각 호스트 머신에서 열어두어야 원활한 통신 가능
docker swarm join --token {출력 token 값} {통신 IP:PORT} 으로 워커 노드 추가
- 주기적으로 토큰 값을 변경하는게 안전
- docker swarm join-token --rotate {worker|manager}
클러스터에 정상적으로 추가되었는지는 docker node ls로 확인
클러스터에서 나가는건 해당 워커 노드에서 docker swarm leave
- 매니저에서는 down 상태로 인식하기 때문에 실제로 관리 대상에서 제외하려면 docker node rm {worker node name}
- 매니저 노드는 docker swarm leave --force
워커 노드를 매니저 노드로 변경하려면 docker node promote {worker node name}
매니저 노드를 워커 노드로 변경하려면 docker node demote {manager node name}

서비스

스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스
- 같은 이미지에서 생성된 컨테이너 집합
- 서비스 내에 컨테이너는 1개 이상 존재
- 컨테이너들은 각 워커 노드와 매니저 노드에 할당되며 이 서비스 내의 컨테이너 배포 단위를 태스크(task)라고 함
서비스에 설정된 레플리카 수만큼의 컨테이너가 스웜 클러스터 내에 유지됨
- 운영 중 하나의 노드가 다운되면 해당 노드에서 실행되던 컨테이너는 다른 노드에서 실행
서비스 생성은 docker service create [--name, --replicas 등등 옵션들] {image}
- detached 모드로 실행되며 당연히 컨테이너 내부에 계속 실행되는 프로세스가 없으면 정지 > 장애로 판단해서 다시 생성 반복
생성한 서비스의 숫자를 늘리려면 `docker service scale {service name=원하는 레플리카 수}
모든 노드에 컨테이너를 반드시 하나씩 생성하는 글로벌 모드는 --mode global을 추가
- docker service create --name study --mode global nginx
노드 간에 변수 등을 넘기기 위해서 secret이나 config 사용
- docker secret create {secret name} {value 혹은 value가 저장된 파일}
- 생성된 secret은 컨테이너 내부의 /run/secrets/디렉터리에 마운트
  - docker service create ... --secret source={생성한 secret name},target={컨테이너 내부에 저장할 이름} -e {env name}="/run/secrets/target 값} ...
  - docker service create --secret source=test,target=mysql_pass -e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/mysql_pass" ...
- 경로나 값 등을 직접 기입하지 말고 호스트의 환경 변수 등을 이용하자
- docker config create {config name} {value 혹은 value가 저장된 파일}
  - 입력된 값은 base64로 인코딩 됨
  - `docker service create ... --config source={생성한 config name},target=
서비스의 업데이트는 docker service update --image {업데이트 대상 이미지} {service name}
- 자체적으로 롤링 업데이트를 지원
- 서비스를 생성할 때 업데이트 주기, 동시 업데이트 컨테이너 수, 실패 대응 등을 설정할 수 있음
  - docker service create --replicas 4 --update-delay 15s --update-parallelism 3 --update-failure-action ...
- 롤백은 docker service rollback {service name}
서비스 목록은 docker service ls
서비스의 자세한 정보는 docker service ps {service name}
- docker service inspect 혹은 docker inspect --type service등으로도 확인 가능
서비스 삭제는 `docker service rm {service name}
- 실행 중인지는 상관없이 바로 삭제
장애 회복을 위해 다른 노드에 컨테이너가 실행된 후 노드가 정상 상태가 되더라도 실행중이던 컨테이너가 복구된 노드에 다시 할당되지 않음(rebalancing이 없음)
- scale 명령어로 컨테이너 수를 줄이고 다시 늘려야함

서비스 네트워크

ingress 네트워크는 로드 밸런싱과 라우팅 메시에 사용

기본적으로 모든 노드가 ingress 네트워크에 연결
- 어떤 스웜 노드에 접근하더라도 서비스 내의 컨테이너에 접근할 수 있게 설정하는 라우팅 메시를 구성
- 로드 밸런싱도 담당
  - 따라서 매니저 노드의 IP로 접근하더라도 다른 워커 노드의 컨테이너에 액세스 되는 경우도 있음
- 오버레이 네트워크 드라이버를 사용
docker_gwbridge 네트워크는 오버레이 네트워크를 사용할 때 사용
- 외부로 나가는 통신 및 오버레이 네트워크의 트래픽 종단점(VTEP) 역할
네트워크도 생성 가능
- docker network create --subnet 159.0.0.0/24 -d {overlay|bridge} {network name}
- 클러스터에 속한 노드 하나에서만 실행해도 다른 노드에 자동 적용
- docker run명령어로 스웜의 오버레이 네트워크를 사용하려면 --net {netowrk name} 옵션을 사용

서비스 디스커버리

서비스의 컨테이너가 늘어나더라도 다른 서비스에서 해당 컨테이너를 인식할 수 있음
- 정확히는 해당 컨테이너를 하나하나 알아야하는게 아니라 해당 서비스'만'알면 되기 때문
- 각 서비스는 VIP를 가지며 내장 DNS 서버에서 어떠한 서비스 이름을 알아서 VIP로 변경

볼륨

컨테이너에서 볼륨을 공유한 것과 똑같이 호스트의 디렉터리 혹은 볼륨을 공유할 수 있음
volume 타입은 다음과 같음
- docker service create ... --mount type=volume,source={volume name},target={container target directory} ...
- source를 지정하지 않으면 임의의 이름을 가진 볼륨이 생성됨
- volume-nocopy옵션을 사용하면 컨테이너의 파일들이 볼륨에 복사되지 않게 할 수 있음
bind 타입은 호스트와 디렉터리를 공유할 때 사용
- docker service create ... --mount type=bind,source={host target directory},target={container target directory} ...
하지만 이렇게 볼륨을 공유하면 모든 노드가 서비스를 할당받을 수 있는 볼륨 데이터를 가지고 있어야하기 때문에 비효율적
- 따라서 되도록이면 네트워크로 접근가능한 외부 스토리지를 이용하는게 바람직

노드 관리

노드의 상태(status)는 변경 가능
- docker node update --availability {active/drain/pause} {node name}
  - active는 컨테이너를 할당받을 수 있는 상태
  - drain은 새로운 컨테이너의 할당을 받지 않으며 실행 중이던 서비스의 컨테이너는 모두 중지되고 active 상태의 노드로 다시 할당
  - pause는 새로운 컨테이너의 할당을 다시 받지 않을 뿐 실행중인 컨테이너는 중지되지 않음
노드에는 키:밸류 형태의 라벨을 추가할 수 있음
- docker node update --label-add {key}={value} {node name} 로 라벨 추가 가능
서비스를 생성할 때 조건(제약)을 설정할 수 있음(--contraint옵션)
- docker service create --constraint 'node.labels.env == dev' ...
  - 라벨 조건
- docker service create --constraint 'node.id == abd3123' ...
  - 노드 아이디 조건
- docker service create --constraint 'node.hostname == {host name} ...
  - 호스트 네임(노드 이름) 조건
- docker service create --constraint 'node.role == {manager|worker}' ...
  - 역할 조건
- docker service create --constraint 'engine.labels.{key} == {value} ...
  - 엔진 라벨 조건
여러 개의 조건도 설정 가능